Communications device providing near field communication (nfc) secure element disabling features related methods

ABSTRACT

A communications device may include a near field communication (NFC) device, at least one memory configured to store secure application data to be communicated via the NFC device and a secure element (SE) application programming interface (API) associated with the secure application data, and a processor coupled with the NFC device and the at least one memory. The processor may be configured to disable the SE API to prevent access to the secure application data based upon a security condition, and enable the SE API to allow access to the secure application data based upon a security restore event.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of provisional application no.61/452,511, filed Mar. 14, 2011, which is hereby incorporated herein inits entirety by reference.

TECHNICAL FIELD

This application relates to the field of communications, and moreparticularly, to wireless communications systems and related methods.

BACKGROUND

Mobile communication systems continue to grow in popularity and havebecome an integral part of both personal and business communications.Various mobile devices now incorporate Personal Digital Assistant (PDA)features such as calendars, address books, task lists, calculators, memoand writing programs, media players, games, etc. These multi-functiondevices usually allow electronic mail (email) messages to be sent andreceived wirelessly, as well as access the internet via a cellularnetwork and/or a wireless local area network (WLAN), for example.

Some mobile devices incorporate contactless card technology and/or nearfield communication (NFC) chips. NFC technology is commonly used forcontactless short-range communications based on radio frequencyidentification (RFID) standards, using magnetic field induction toenable communication between electronic devices, including mobilewireless communications devices. This short-range high frequencywireless communications technology exchanges data between devices over ashort distance, such as only a few centimeters.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram of a communications system inaccordance with an example embodiment.

FIG. 2 is a schematic diagram of the communications system of FIG. 1showing the display of the mobile device.

FIG. 3 is a more detailed schematic diagram of the communications systemof FIG. 1.

FIG. 4 is a flow diagram illustrating example method aspects associatedwith the systems of FIGS. 1-3.

FIG. 5 is a schematic block diagram of a communications system inaccordance with another example embodiment.

FIG. 6 is a flow diagram illustrating example method aspects associatedwith the system of FIG. 5.

FIG. 7 is a schematic block diagram illustrating example mobile wirelesscommunications device components that may be used with the devices ofFIGS. 1-3 and 5.

DETAILED DESCRIPTION

The present description is made with reference to the accompanyingdrawings, in which embodiments are shown. However, many differentembodiments may be used, and thus the description should not beconstrued as limited to the embodiments set forth herein. Rather, theseembodiments are provided so that this disclosure will be thorough andcomplete. Like numbers refer to like elements throughout.

Generally speaking, a communications device is provided herein which mayinclude a near field communication (NFC) device, at least one memoryconfigured to store secure application data to be communicated via theNFC device and a secure element (SE) application programming interface(API) associated with the secure application data, and a processorcoupled with the NFC device and with the at least one memory. Theprocessor may be configured to disable the SE API to prevent access tothe secure application data based upon a security condition, and enablethe SE API to allow access to the secure application data based upon asecurity restore event. Accordingly, the processor may advantageouslyprevent access to the secure application data without having to wait fora trusted service manager (TSM) to authorize deletion of the secureapplication data, for example.

More particularly, the communications device may further include awireless transceiver coupled with the processor, and the securitycondition may comprise initiation of a wipe while the wirelesstransceiver is not in communication with a wireless communicationsnetwork. In accordance with other examples, the communications devicemay further include an input device coupled with the processor, and thesecurity condition may comprise a threshold number of unsuccessfuldevice authentication attempts via the input device, or a securitycommand entered via the input device. Also by way of example, thesecurity restore event may comprise receiving a secure application datadelete command via the wireless transceiver, or receiving a securityrestore command via the input device.

The NFC device may also have an NFC API associated therewith. As such,the processor may be further configured to enable the NFC API for NFCcommunication while the SE API is disabled. Additionally, the processormay be further configured to prevent write access to the memory basedupon the occurrence of the security condition.

A related communications system may include a NFC terminal and acommunications device, such as the one described briefly above. Arelated method for operating a communications device, such as the onedescribed briefly above, may include disabling the SE API to preventaccess to the secure application data based upon a security condition,and enabling the SE API to allow access to the secure application databased upon a security restore event.

A related non-transitory computer-readable medium is for acommunications device such as the one described briefly above. Thenon-transitory computer-readable medium may have computer-executableinstructions for causing the communications device to perform stepscomprising disabling the SE API to prevent access to the secureapplication data based upon a security condition, and enabling the SEAPI to allow access to the secure application data based upon a securityrestore event.

Referring initially to FIGS. 1-2, a communications system 30illustratively includes a near field communication (NEC) terminal 31associated with an object, and a mobile wireless communications device32 (also referred to as a “mobile device” herein). Example mobilewireless communications devices may include portable or personal mediaplayers (e.g., music or MP3 players, video players, electronic bookreaders, etc.), portable gaming devices, portable or mobile telephones,smartphones, tablet computers, digital cameras, etc.

The mobile device 32 illustratively includes a portable housing 33 and awireless transceiver 34 carried by the portable housing 33. The wirelesstransceiver 34 may comprise a cellular transceiver or other type ofwireless communications transceiver, and may communicate any combinationof voice and data, such as, for example, email. The wireless transceiver34 may communicate with a security server 36 that may provide one ormore of remote instructions and provisioning operations to the mobiledevice 32.

The mobile device 32 includes a display 46 carried by the portablehousing 33. The display 46 may comprise a liquid crystal display (LCD),for example, and may be configured to display information relating todata or voice communications. The display 46 may be in the form of anactive display that includes a backlight, for example. The display 46may display email information, contact information, or call information.The display 46 may be another type of display, for example, a passivedisplay, and may display other information.

The mobile device 32 also includes an input device 45. The input device45 may be a keypad, touch-screen display, or other input device, forexample.

The mobile device 32 also includes a processor 35 that is carried by theportable housing 33 and coupled with the wireless transceiver circuitry34, the input device 45, and the display 46. The processor 35 may beimplemented using hardware (e.g., memory, etc.) and software components,i.e., computer-readable instructions for causing the mobile device 32 toperform the various functions or operations described herein.

The mobile device 32 also includes an NFC device 40 carried by theportable housing and coupled with the processor 35. The NFC device 40includes a NFC controller 41 and a NFC transceiver 42 coupled with theNFC controller 41. The NFC controller 41 and the NFC transceiver 42advantageously cooperate to perform at least one NFC communicationfunction. For example, the NFC device 40 may communicate with the NFCterminal 31 based upon proximity thereto using NFC communication. TheNFC terminal 31 may be a NFC tag, a NFC-enabled mobile device, a smartposter, etc.

By way of background, NFC is a short-range wireless communicationstechnology in which NFC-enabled devices are “swiped,” “bumped” orotherwise moved in close proximity to communicate. In one non-limitingexample implementation, NFC may operate at 13.56 MHz and with aneffective range of several centimeters, typically 4 cm or less, butother suitable versions of near-field communication which may havedifferent operating frequencies, effective ranges, etc., for example,may also be used.

The NFC device 40 also includes a first memory 43 coupled to the NFCcontroller 41. More particularly, the first memory 43 may be embeddedwithin the NFC device hardware or within the NFC integrated circuit(IC). The first memory 43 may be tamper resistant, for example. In otherwords, the first memory 43 may comprise a secure element. The firstmemory 43 or secure element, may store applications relating to NFCcommunications, or contactless applications for communicating with theNFC terminal 31. For example, the applications may include financialpayment applications, secure access system applications, loyalty cardapplications, and other applications, and may be encrypted. In someexample embodiments, the first memory 43 may store only one application.

The mobile device 32 also includes a second memory 44. The second memory44 may comprise the device memory, for example. In other words, thesecond memory 44 may include operating system files, applications, andother device data. In some example embodiments, the second memory 44 maybe part of the universal integrated circuit card (UICC), for example.The second memory 44 may also be removable, and may be a secure-digital(SD) card or a subscriber identity module (SIM) card, for example. Thesecond memory 44 may comprise another type of memory, for example aflash memory. While first and second memories 43, 44 are describedherein, more than two memories may be used. In other words,applications, or secure elements, may be stored in or spread overvarious memory devices. It should also be noted that a secure elementmay be implemented in a dedicated or secure area of a common memory, forexample. In addition, multiple secure elements may be used.

The processor 35 may be configured to disable the NFC transceiver 42based upon a security condition. A security condition may occur when auser of the device 32 cannot be authenticated, for example, as a resultof the device 32 receiving too many incorrect password entries via theinput device 45. Alternatively, the security condition may occur whenthe device 32 receives, via the input device 45, a command to performoperations associated with a security condition. This may occur, forexample, in the context of a user who will no longer be using the device32 and is preparing to give away the device 32 to another user or tradein the device 32 for a new device, for example. These operations may becollectively referred to as a “wipe”. Still further, a securitycondition may occur when the device 32 receives a remote command, e.g.,a remote wipe command, indicating a security condition, for example,from a system administrator. This may occur, for example, in the contextof a lost or stolen or otherwise compromised device. However, auser-initiated wipe may also occur when the mobile device 32 is not incommunication with a network, i.e., it is out of coverage (e.g.,wireless coverage, data coverage, radio coverage, etc., for example.

If a security condition is detected, the processor 35 may be configuredto disable access to the applications on the first memory 43, e.g.,secure payment applications. Disabling is performed since the mobiledevice 32 typically does not have unlimited read/write access to thefirst memory 43 since the first memory does not inherently “trust” themobile device 32. That is, secure data or applications stored on thefirst memory 43 typically may not be modified except by a trusted thirdparty source, as will be discussed further below. Thus, the securityserver 36 is able to initiate a wipe of the first memory 43 based uponcommunication therewith, as will be described in further detail below.That is, the ability for a mobile device application to interact with anapplication on a secure element may be disabled via the basebandinterface. Another example approach is to use a mobile deviceapplication to disable the ability of an application on the secureelement to communicate via the NFC transceiver 42.

After disabling access to the applications on the first memory 43, theprocessor 35 is configured to erase the contents, or second applicationfrom the second memory 44, or device memory. In other words, the mobiledevice 32 is wiped.

The processor 35 performs a reset operation after successfully erasingthe applications from the second memory 44. In other words, the resetoperation may be based upon a successful wipe. The reset operation maybe performed by selectively disabling a power source 37 carried by thehousing 33 and coupled to the processor 35. In other words, the resetoperation may comprise a power down/power up cycle of the mobile device32. The power source 37 may comprise a battery cell, for example. Insome example embodiments, a reset operation may not be performed.

The processor 35 is also configured to erase the applications from thefirst memory 43 after the reset operation. The processor 35 may erasethe applications based upon a command received from the security server36 via the wireless transceiver 34 after the reset operation. Theprocessor 35, after the applications are deleted or wiped from the firstmemory 44, is configured to enable access to the NFC transceiver.

In some example embodiments, the contents, or second application fromthe second memory 44, may not be erased based upon a security condition.Based upon a security condition, the application on the first memory 43may be erased while selectively maintaining the second application onthe second memory 44. In other words, the processor 35 may be configuredto erase the application from the first memory 43 without performing thesteps of erasing the second application and resetting.

Referring now to FIG. 3, in one advantageous example embodiment, thefirst memory 43 may comprise an embedded secure element (eSE). An eSEcomprises an integrated circuit (IC) that manages and includescredentials (e.g., credentials associated with various credit cards,bank cards, gift cards, access cards, transit passes, etc.) that havebeen provisioned to the mobile device 32. In an example embodiment, theeSE 43 may run based upon a GlobalPlatform card specification and becompatible with a Java Card Platform Specification, for example. The eSE43 may run or be compatible with other or additional platforms.

Within the eSE 43, GlobalPlatform is responsible for managing thelifecycle of other applets, and for providing them with securityservices (e.g., allowing application security domains to be created).Security domains maintain a lifecycle state for each applet (e.g.,active, locked, etc.), manage the keys for authenticated access to anapplet, and serve as an endpoint when a secure channel is establishedbetween a security server 36, i.e., trusted service manager (TSM) and anapplet. The security server 36 or TSM is typically responsible forprovisioning and managing the applets within its security domain on thefirst memory 43.

RF readers, and more particularly, NFC readers, for example, the NFCterminal 31 may communicate with the applets that are installed on theeSE 43 via the NFC controller 41 and NFC transceiver 43. A reader, orNFC terminal 31 first selects an applet by its applet identifier (AID),GlobalPlatform checks for the existence of the applet in question (andverifies that the applet is in the correct lifecycle state), and thenfurther application protocol data units (APDUs) sent by the reader arerouted to the applet by GlobalPlatform. Generally, the RF readers, forexample, the NFC terminal 31, do not open secure channels to thesecurity domains, and any authentication that occurs with the NFCterminal is the responsibility of the specific applet that getsselected.

The TSM 36 may open a secure channel to the issuer security domain (ISD)via the mobile device 32, by authenticating itself using the appropriateISD keys. An ISD is considered the security endpoint that communicateswith the root TSM and allow for installation of applets and managementof application security domains (ASDs). To the mobile device 32, thissecure channel is entirely opaque. The TSM 36 may then manage applets(e.g., install and delete them, change their lifecycle states) andmanage the application security domains on the eSE 43. Afterestablishing a secure channel with a security domain, the TSM 36 canthen send APDUs to the applets that belong to that security domain. Theapplet can determine that it is communicating with its TSM 36 over asecure channel, and can thus allow access to privileged or“administrative” commands.

The eSE 43 typically does not “trust” the mobile device 32 to the samedegree as the TSM 36, since GlobalPlatform may not intend for a mobiledevice to have access to the keys that are needed to open a securechannel. However, an applet can determine that it is communicating overthe baseband interface and thus allow access to commands that would nototherwise be available. The baseband interface generally refers to aninterface for communications between the processor 35 and the eSE 43, orfirst memory, (via the NFC controller 41). This may include commandsthat are sent from the wireless transceiver 34, for example, that arethen sent to the eSE 43 across the baseband interface.

For example, a credit card applet may allow the baseband interface toplace it in a “visible” or “hidden” state, while allowing access to thenecessary commands for a typical financial transaction over the NFCtransceiver 42 or RF interface. It should be noted that due to thisrestriction, the mobile device 32 may not “wipe” the eSE 43 in aconventional sense. Based on the interfaces and application programminginterfaces (APIs) provided by GlobalPlatform, there is typically no wayfor the mobile device 32 to delete an applet or, for that matter, evento enumerate the applets that are installed/instantiated on the eSE 43.

Based on the restrictions described earlier, it may be increasinglydifficult for the mobile device 32 to directly delete applets from theeSE 43. However, it may be unacceptable for a mobile device to delay awipe until such time that the TSM 36 could be contacted to wipe the eSE43, especially given that an attacker might remove the mobile deviceSIM, or any other persistent memory device, i.e., the second memory 44,to ensure it does not have coverage.

In the present embodiments, the processor 35 takes steps to ensure dataand access to the eSE 43 is prevented when the mobile device wipe istriggered (effectively resembling a wipe of the eSE 43 to the end user)and will result in the eSE being wiped at the next possible opportunity,i.e., whenever the mobile device 32 has coverage and is able to contactthe TSM 36.

The eSE 43 may include applets or other code to perform the wipeprocess. More particularly, the eSE 43 may include one or more emulationlayers, for example, the MIFARE and iClass emulation layers. Theemulation layers may not be directly linked to applets or other code onthe eSE 43, for example. The applet generally includes security keys forwriting to its corresponding emulation layer, for example, for theMIFARE emulation class, this would be K_MIFARE, which is derived fromK_A and K_B for a specific block of MIFARE memory. Each of the wipeapplets may be installed and instantiated by the TSM 36. The applets maybe visible over the baseband interface, and it may respond to a specificAPDU that may trigger it to wipe its corresponding emulation layer usingthe security keys, for example.

The ISD lifecycle state can be moved to card lock, effectively disablingaccess to all applets on the eSE 43 by an applet provided that it isgranted the card lock privilege. Thus, a wipe applet can be installedand instantiated by the TSM 36 to the ISD and given card lockprivileges. The applet may be only visible over the baseband interface,and may respond to a specific APDU that triggers it to move the ISDlifecycle state to card lock. Additional code may be used so thatcertain portions, for example, internal code, can communicate with thisapplet.

In a normal operating state, the user uses the mobile device 32 normallyfor voice and/or data communications. For example, if the user uses awallet application and the TSM 36 has installed anything to their mobiledevice's eSE 43, the TSM installs and instantiates the “wipe applet” tothe ISD, and asserts a persistent flag indicating the eSE 43 is in use.If, at some point, the eSE 43 is provisioned with an emulation layercredential, for example, the corresponding emulation layer wipe appletwould be installed and instantiated at this time. For example, if theeSE 43 is provisioned with a MIFARE credential, then the MIFARE wipeapplet would be installed and instantiated at this time.

In a first step, the wipe is triggered. As noted above, the mobiledevice wipe may be triggered in multiple ways, for example, receipt oftoo many incorrect password entries via the input device 45 in anattempt to gain access to the mobile device 32, receipt of a local wipecommand, e.g., comprising a “wipe” option on the mobile device, or aremote wipe command may be sent. In the remote wipe case, anacknowledgement may be sent, for example. It is worthwhile noting thatthe wipe may not be delayed if this acknowledgement is not sent.

In a second step, access to the processing interface for communicatingwith the eSE 43 and the transceiver 42 is prevented or restricted. If apersistent flag indicating the eSE 43 has been personalized, the mobiledevice wipe code may assert a persistent flag indicating the eSE 43 hasbeen locked. Each of the above-noted persistent flags may be set orcleared. The eSE primary interface APIs and the NFC transceiver APIscheck the value of a persistent flag indicating that the eSE 43 has beenlocked when they are called. If it is asserted, the eSE primaryinterface APIs typically should ignore any call not coming from aninternal or trusted module, and the NFC transceiver APIs should disableall access to the card emulation mode.

In a third step, each emulation layer is wiped. The wipe APDU is sent tothe corresponding wipe applet over the baseband interface. The appletwipes personalization data in the emulation layer. More particularly,for example, the wipe APDU may wipe the personalization data in theiClass and MIFARE emulation layers.

In a fourth step, the eSE 43/ISD is moved to a card locked state. Thewipe APDU is sent to the wipe applet over the baseband interface. Theapplet moves the ISD state to card locked, effectively denying access toapplets and security domains on the eSE 43. It should be noted that thisstep should take place after the third step, since otherwisecommunication may not be possible with the applets that wipe theemulation layers in those steps. After this step, although the eSE 43still includes personalized applets, these applets are no longeraccessible to anyone but the TSM 36. From the end user's perspective,the eSE 43 is “wiped”.

In a fifth step, the mobile device 32 is wiped. The mobile device 32 iswiped by operating system (OS) code, for example.

In a sixth step, the mobile device 32 restarts. The mobile device 32restarts after the wipe is successful.

In a seventh step, an eSE proxy (not shown) signals the TSM 36. The eSEproxy starts up and detects that the ISD is in a card locked state (byattempting to select the ISD over the baseband interface, or by checkingthe persistent flag indicating the eSE 43 has been locked. It then waitsfor a data connection and signals the TSM 36 that the eSE 43 needs to bewiped.

In an eighth step, the eSE 43 is wiped. The TSM 36 deletes all appletsfrom the eSE 43. It should be noted that in some embodiments, selectiveaccess to the eSE 43 may be provided over the baseband interface. Forexample, an application from a mobile device manufacturer may be allowedto access the eSE 43 for the purposes of wiping the eSE, while accessfrom third party applications may be restricted.

In a ninth step, access to eSE primary interface APIs and the NFCtransceiver 42 are restored. Once the TSM 36 is satisfied that allapplets have been deleted from the eSE 43, it signals the eSE proxy thata persistent flag indicating the eSE 43 has been locked. At this stage,eSE primary interface APIs are unlocked to third parties, and the NFCtransceiver 42 is permitted to enter card emulation mode again. The eSE43, at this point, has been reset to a factory state. It should be notedthat in different embodiments steps other steps may be performed, orsome steps may be performed in different orders.

Referring now to the flowchart 60 of FIG. 4, related method aspects arenow described. Beginning at Block 62, the processor 35 determineswhether a security condition has been initiated (Block 64). For example,the securing condition may comprise a wipe, or entering a wrong passworda given number of times (which may also trigger a wipe in someembodiments). If a security condition is determined, the processor 35disables the NFC transceiver 42 (Block 66). The processor 35 thendisables access to the first plurality of applications on the firstmemory 43 (Block 68). At Block 70, the processor 35 erases the secondapplication from the second memory 44. A reset operation is performed bythe processor 35 (Block 72). At Block 74, the security server 36 sends asignal to the processor 35 via the wireless transceiver 34 once aconnection is established therewith. At Block 76 the processor 35 erasesthe first plurality of applications from the first memory 43 if thesignal from the security server 36 is received. The NFC transceiver 42at Block 78 is re-enabled after the first plurality of applications iserased. The method ends at Block 80.

Turning now to FIG. 5, a related communications system 130illustratively includes an NFC terminal 131, a communications device 132(e.g., a mobile wireless communication device), and a security server136, which are similar to those described above. In particular, in thepresent example the communications device 132 illustratively includes ahousing 133 carrying a wireless transceiver 134, a NFC device 140, aninput device(s) 145, a display 146, one or more memories 147, and aprocessor 135. The wireless transceiver 134, NFC device 140, inputdevice 145, display 146, and memory 147 are illustratively coupled withthe processor 135, and these components are similar to the counterpartcomponents described above except as otherwise described below.

The NFC device 140 has one or more NFC APIs 150 associated therewith.Moreover, the memory 147 may be part of the NFC device 140 in someembodiments, it may be a separate memory (e.g., SD card, SIM card,etc.), or both types of memories may be used, as noted above. In thepresent example, the memory 147 illustratively includes secure element(SE) application data 148 to be communicated via the NFC device 140(e.g., a secure applet, account information, etc.), and an SE API 149associated with the secure application data. As noted above, the APIcontrols access to the SE application data 148 stored in the memory 147.

As also noted above, SEs are where NFC applets such as payment (e.g.,credit or debit card, etc.), transit, physical access control, and othersecure applications are stored. In conjunction with the NFC device 140,the SE will allow the mobile device 132 to act as a payment or accesscard, for example. Typically, installation and removal or deletion ofapplications from an SE may only be performed by a third party entitythat holds the master keys (i.e., issuer security domain keys) toauthenticate with the SE. The third party entity (e.g., TSM) may open acryptographically secure channel to the secure element (e.g., using aproxy application running on the mobile device 132 to access the SE).For example, when a credit card applet is to be installed on the SE ofthe mobile device 132, the TSM, after receiving the appropriateinstructions from the given bank, will open a secure channel to a secureelement and install the appropriate credit card applet. Subsequently, ifthe credit card applet is to be removed or deleted, the TSM will removeit.

Such TSM operations require a communications link between the proxy andthe TSM (typically an over-the-air connection in the case of a mobilewireless communications device, as described above). Again, this maycreate a problem in that if the user wants to wipe the mobile device 132before giving it away or disposing of it, etc., the user may not havecoverage, either because of being out of wireless communications range,account cancellation, SIM card removal, etc. Without coverage, the TSMwill not be able to issue the appropriate delete commands, so even aftera security wiping of the mobile device 132, the memory 147 will stillretain all of the SE application data 148. Thus, for example, a creditcard may still be used after the mobile device 132 is wiped and handedoff to another user.

With further reference to the flow diagram 160 of FIG. 6, beginning atBlock 162, the processor 135 is configured to disable the SE API 149 toprevent access to the SE application data 148 based upon a securitycondition such as a device wipe, at Blocks 164, 166. In particular, thedisabling may occur despite the wireless transceiver 134 not being incommunication with the security server 136 (e.g., TSM) via a wirelesscommunications network. Another security condition that may triggerdisabling of the SE API 149 may include a threshold number ofunsuccessful access attempts to access the mobile device 132 via theinput device 145 (e.g., incorrectly entered passwords, etc.), as notedabove.

Still another security condition that may trigger disabling of the SEAPI 149 is a security command entered via the input device 145. Forexample, in some instances a user may desire to temporarily disable theSE application data 148 so that the mobile device 132 may be loaned toanother user without allowing the other user to access the SE data, butnot completely wipe the mobile device. In such cases, a security command(e.g., selection of a security option from an on-screen menu, etc.) maybe used to temporarily cause the processor 135 to disable the SE API 149so that the SE application data 148 may not be accessed.

In some embodiments, write access to the memory 147 may optionally beselectively disabled while the SE API is disabled, at Block 168. Thatis, the processor 135 may prevent any further SE data from being writtento or installed on the memory 147 by TSMs until the security conditionhas been resolved, as will be discussed further below. However, in theinterim, the processor 135 may optionally enable (or continue to allow)the NFC API 150 to perform NFC communication while the SE API 149remains disabled for other NFC applications that do not require accessto the SE data 148, at Block 147.

The processor 135 may enable the SE API 149 to again allow access to theSE data 148 based upon a security restore event, at Blocks 172, 174,which concludes the illustrated method (Block 176). Accordingly, theprocessor 135 may advantageously prevent access to the SE data 148without having to wait for a TSM to authorize deletion of the secureapplication data, for example. By way of example, the security restoreevent may include receiving a secure application data delete command viathe wireless transceiver 134, such as a delete command from the TSM thatissued the SE data 148. In the case of a user that temporarily disablesthe SE API 149 as described above, the security restore event maycomprise providing a secure password, biometric, etc., to restore NFCcommunication for the SE API.

Accordingly, the processor 135 is advantageously able to disable orsuspend the SE API 149 and the ability for the NFC device 140 to routeNFC traffic to the SE API if a security condition occurs. Thus, afterthe mobile device 132 is wiped, etc., even though SE data 148 remains inthe memory 147, the processor 135 prevents NFC device 140 traffic frombeing routed to or from the SE API 149. As such, the SE data 148 may notbe accessed by the NFC terminal 131 (e.g., an external point-of-saleterminal) for the purposes of performing a payment or other securetransaction.

Moreover, the processor 135 may, for example, only allow NFC device 140traffic to resume routing to the SE API 149 after a delete command hasbeen successfully received from the TSM and injected to delete the SEapplication data 148, etc. This way, it may be assured that the SE data148 has been deleted before allowing a next user, for example, toactivate NFC device 140 communication routing to the memory 147. In someexample embodiments, the processor 135 may also lock baseband access tothe SE data 148 (e.g. through JSR-177) unless the baseband access isbeing used to issue a delete command. Once the delete command has beenissued, baseband access may be reinstated.

This example approach provides several advantages. For example, themobile device 132 may be wiped at any time, regardless of whether it hascoverage or whether there is a SIM inserted, without having to wait fora TSM to issue delete commands to the secure element to ensure SE data148 protection. Then, before the SE API 149 or SE data 148 mayeffectively be used again, the processor 135 will enforce receipt of acryptographically protected delete command from the TSM (in the case ofa device wipe security condition) or appropriate security credentialsbefore allowing the SE API 149 to be used again, such as through the NFCdevice 140 or the wireless transceiver 134.

A related non-transitory computer-readable medium example embodiment mayhave computer-executable instructions for causing the communicationsdevice 132 to perform steps including disabling the SE. API 149 toprevent access to the SE data 148 based upon a security condition, andenabling the SE API to again allow access to the SE data based upon asecurity restore event, as described further above. The non-transitorycomputer-readable medium may perform additional steps described above aswell.

Example components of a mobile wireless communications device 1000 thatmay be used in accordance with the above-described embodiments arefurther described below with reference to FIG. 7. The device 1000illustratively includes a housing 1200, a keyboard or keypad 1400 and anoutput device 1600. The output device shown is a display 1600, which maycomprise a full graphic LCD. Other types of output devices mayalternatively be utilized. A processing device 1800 is contained withinthe housing 1200 and is coupled between the keypad 1400 and the display1600. The processing device 1800 controls the operation of the display1600, as well as the overall operation of the mobile device 1000, inresponse to actuation of keys on the keypad 1400.

The housing 1200 may be elongated vertically, or may take on other sizesand shapes (including clamshell housing structures). The keypad mayinclude a mode selection key, or other hardware or software forswitching between text entry and telephony entry.

In addition to the processing device 1800, other parts of the mobiledevice 1000 are shown schematically in FIG. 7. These include acommunications subsystem 1001; a short-range communications subsystem1020; the keypad 1400 and the display 1600, along with otherinput/output devices 1060, 1080, 1100 and 1120; as well as memorydevices 1160, 1180 and various other device subsystems 1201. The mobiledevice 1000 may comprise a two-way RF communications device having dataand, optionally, voice communications capabilities. In addition, themobile device 1000 may have the capability to communicate with othercomputer systems via the Internet.

Operating system software executed by the processing device 1800 isstored in a persistent store, such as the flash memory 1160, but may bestored in other types of memory devices, such as a read only memory(ROM) or similar storage element. In addition, system software, specificdevice applications, or parts thereof, may be temporarily loaded into avolatile store, such as the random access memory (RAM) 1180.Communications signals received by the mobile device may also be storedin the RAM 1180.

The processing device 1800, in addition to its operating systemfunctions, enables execution of software applications 1300A-1300N on thedevice 1000. A predetermined set of applications that control basicdevice operations, such as data and voice communications 1300A and1300B, may be installed on the device 1000 during manufacture. Inaddition, a personal information manager (PIM) application may beinstalled during manufacture. The PIM may be capable of organizing andmanaging data items, such as e-mail, calendar events, voice mails,appointments, and task items. The PIM application may also be capable ofsending and receiving data items via a wireless network 1401. The PIMdata items may be seamlessly integrated, synchronized and updated viathe wireless network 1401 with corresponding data items stored orassociated with a host computer system.

Communication functions, including data and voice communications, areperformed through the communications subsystem 1001, and possiblythrough the short-range communications subsystem. The communicationssubsystem 1001 includes a receiver 1500, a transmitter 1520, and one ormore antennas 1540 and 1560. In addition, the communications subsystem1001 also includes a processing module, such as a digital signalprocessor (DSP) 1580, and local oscillators (LOs) 1601. The specificdesign and implementation of the communications subsystem 1001 isdependent upon the communications network in which the mobile device1000 is intended to operate. For example, a mobile device 1000 mayinclude a communications subsystem 1001 designed to operate with theMobitex™, Data TAC™ or General Packet Radio Service (GPRS) mobile datacommunications networks, and also designed to operate with any of avariety of voice communications networks, such as AMPS, TDMA, CDMA,WCDMA, PCS, GSM, EDGE, etc. Other types of data and voice networks, bothseparate and integrated, may also be utilized with the mobile device1000. The mobile device 1000 may also be compliant with othercommunications standards such as 3GSM, 3GPP, UMTS, 4G, etc.

Network access requirements vary depending upon the type ofcommunication system. For example, in the Mobitex and DataTAC networks,mobile devices are registered on the network using a unique personalidentification number or PIN associated with each device. In GPRSnetworks, however, network access is associated with a subscriber oruser of a device. A GPRS device therefore typically involves use of asubscriber identity module, commonly referred to as a SIM card, in orderto operate on a GPRS network.

When required network registration or activation procedures have beencompleted, the mobile device 1000 may send and receive communicationssignals over the communication network 1401. Signals received from thecommunications network 1401 by the antenna 1540 are routed to thereceiver 1500, which provides for signal amplification, frequency downconversion, filtering, channel selection, etc., and may also provideanalog to digital conversion. Analog-to-digital conversion of thereceived signal allows the DSP 1580 to perform more complexcommunications functions, such as demodulation and decoding. In asimilar manner, signals to be transmitted to the network 1401 areprocessed (e.g. modulated and encoded) by the DSP 1580 and are thenprovided to the transmitter 1520 for digital to analog conversion,frequency up conversion, filtering, amplification and transmission tothe communication network 1401 (or networks) via the antenna 1560.

In addition to processing communications signals, the DSP 1580 providesfor control of the receiver 1500 and the transmitter 1520. For example,gains applied to communications signals in the receiver 1500 andtransmitter 1520 may be adaptively controlled through automatic gaincontrol algorithms implemented in the DSP 1580.

In a data communications mode, a received signal, such as a text messageor web page download, is processed by the communications subsystem 1001and is input to the processing device 1800. The received signal is thenfurther processed by the processing device 1800 for an output to thedisplay 1600, or alternatively to some other auxiliary I/O device 1060.A device may also be used to compose data items, such as e-mailmessages, using the keypad 1400 and/or some other auxiliary I/O device1060, such as a touchpad, a rocker switch, a thumb-wheel, or some othertype of input device. The composed data items may then be transmittedover the communications network 1401 via the communications subsystem1001.

In a voice communications mode, overall operation of the device issubstantially similar to the data communications mode, except thatreceived signals are output to a speaker 1100, and signals fortransmission are generated by a microphone 1120. Alternative voice oraudio I/O subsystems, such as a voice message recording subsystem, mayalso be implemented on the device 1000. In addition, the display 1600may also be utilized in voice communications mode, for example todisplay the identity of a calling party, the duration of a voice call,or other voice call related information.

The short-range communications subsystem enables communication betweenthe mobile device 1000 and other proximate systems or devices, whichneed not necessarily be similar devices. For example, the short-rangecommunications subsystem may include an infrared device and associatedcircuits and components, a Bluetooth™ communications module to providefor communication with similarly-enabled systems and devices, or a nearfield communications (NFC) sensor for communicating with a NFC device orNFC tag via NFC communications.

Many modifications and other embodiments will come to the mind of oneskilled in the art having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it isunderstood that various modifications and embodiments are intended to beincluded within the scope of the appended claims.

1. A communications device comprising: a near field communication (NFC)device; at least one memory configured to store secure application datato be communicated via said NFC device and a secure element (SE)application programming interface (API) associated with the secureapplication data; and a processor coupled with said NFC device and withsaid at least one memory, the processor being configured to disable theSE API to prevent access to the secure application data based upon asecurity condition, and enable the SE API to allow access to the secureapplication data based upon a security restore event.
 2. Thecommunications device of claim 1 further comprising a wirelesstransceiver coupled with said processor; and wherein the securitycondition comprises initiation of a wipe while said wireless transceiveris not in communication with a wireless communications network.
 3. Thecommunications device of claim 1 further comprising an input devicecoupled with said processor; and wherein the security conditioncomprises a threshold number of unsuccessful device authenticationattempts via said input device.
 4. The communications device of claim 1further comprising an input device coupled to said processor; andwherein the security condition comprises a security command entered viasaid input device.
 5. The communications device of claim 1 furthercomprising a wireless transceiver coupled with said processor; andwherein the security restore event comprises receiving a secureapplication data delete command via said wireless transceiver.
 6. Thecommunications device of claim 1 further comprising an input devicecoupled with said processor; and wherein the security restore eventcomprises receiving a security restore command via said input device. 7.The communications device of claim 1 wherein said NFC device has an NFCAPI associated therewith; and wherein said processor is furtherconfigured to enable said NFC API for NFC communication while the SE APIis disabled.
 8. The communications device of claim 1 wherein saidprocessor is further configured to disable write access to said memorybased upon the occurrence of the security condition.
 9. A communicationssystem comprising: a near field communication (NFC) terminal; and acommunications device configured to communicate with said NFC terminal,the communications device comprising a NFC device, at least one memoryconfigured to store secure application data to be communicated via saidNFC device to said NFC terminal and a secure element (SE) applicationprogramming interface (API) associated with the secure application data,and a processor coupled with said NFC device and with said at least onememory, the processor being configured to disable the SE API to preventaccess to the secure application data based upon a security condition,and enable the SE API to allow access to the secure application databased upon a security restore event.
 10. The communications system ofclaim 9 wherein said communications device further comprises a wirelesstransceiver coupled with said processor; and wherein the securitycondition comprises initiation of a wipe while said wireless transceiveris not in communication with a wireless communications network.
 11. Thecommunications system of claim 9 wherein said communications devicefurther comprises an input device coupled with said processor; andwherein the security condition comprises a threshold number ofunsuccessful device authentication attempts via said input device. 12.The communications system of claim 9 wherein said communications devicefurther comprises an input device coupled to said processor; and whereinthe security condition comprises a security command entered via saidinput device.
 13. The communications system of claim 9 wherein saidcommunications device further comprises a wireless transceiver coupledwith said processor; and wherein the security restore event comprisesreceiving a secure application data delete command via said wirelesstransceiver.
 14. The communications system of claim 9 wherein saidcommunications device further comprises an input device coupled withsaid processor; and wherein the security restore event comprisesreceiving a security restore command via said input device.
 15. A methodfor operating a communications device comprising a near fieldcommunication (NFC) device and at least one memory configured to storesecure application data to be communicated via the NFC device and asecure element (SE) application programming interface (API) associatedwith the secure application data, the method comprising: disabling theSE API to prevent access to the secure application data based upon asecurity condition; and enabling the SE API to allow access to thesecure application data based upon a security restore event.
 16. Themethod of claim 15 wherein the communications device further comprises awireless transceiver coupled with the processor; and wherein thesecurity condition comprises initiation of a wipe while the wirelesstransceiver is not in communication with a wireless communicationsnetwork.
 17. The method of claim 15 wherein the communications devicefurther comprises an input device; and wherein the security conditioncomprises a threshold number of unsuccessful device authenticationattempts via the input device.
 18. The method of claim 15 wherein thecommunications device further comprises an input device; and wherein thesecurity condition comprises a security command entered via the inputdevice.
 19. The method of claim 15 wherein the communications devicefurther comprises a wireless transceiver coupled with the processor; andwherein the security restore event comprises receiving a secureapplication data delete command via the wireless transceiver.
 20. Anon-transitory computer-readable medium for a communications devicecomprising a near field communication (NFC) device and at least onememory configured to store secure application data to be communicatedvia the NFC device and a secure element (SE) application programminginterface (API) associated with the secure application data, thenon-transitory computer-readable medium having computer-executableinstructions for causing the communications device to perform stepscomprising: disabling the SE API to prevent access to the secureapplication data based upon a security condition; and enabling the SEAPI to allow access to the secure application data based upon a securityrestore event.
 21. The non-transitory computer-readable medium of claim20 wherein the communications device further comprises a wirelesstransceiver; and wherein the security condition comprises initiation ofa wipe while the wireless transceiver is not in communication with awireless communications network.
 22. The non-transitorycomputer-readable medium of claim 20 wherein the communications devicefurther comprises an input device; and wherein the security conditioncomprises a threshold number of unsuccessful device authenticationattempts via the input device.
 23. The non-transitory computer-readablemedium of claim 20 wherein the communications device further comprisesan input device; and wherein the security condition comprises a securitycommand entered via the input device.
 24. The non-transitorycomputer-readable medium of claim 20 wherein the communications devicefurther comprises a wireless transceiver; and wherein the securityrestore event comprises receiving a secure application data deletecommand via the wireless transceiver.